IBIS Macromodel Task Group Meeting date: 04 September 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki * Ming Yan Stephen Slater Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to email the ATM regarding ideas on the proper definition of Vref. - Done. - Randy to investigate if/why/how a clock waveform input might be used. - In progress. Arpad noted that Justin had given a presentation last week that touched on the subject, but a direct answer is still pending. - Michael M. to investigate if/why/how a clock waveform input might be used. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 28 meeting. Curtis moved to approve the minutes. Ambrish seconded the motion. There were no objections. ------------- New Discussion: Vref definition: Arpad noted the previous week's discussion regarding the Vref topic and the need for a precise definition before we could start any work on a BIRD. Ken noted that he agreed with Walter's reply to Arpad's Vref email (see ARs above). He noted that VcentDQ and VcentCA are the important values. He said Vcent** values are derived from the analog waveforms. You need to do it for each waveform (for all the data lines, for example). Then you take the highest and lowest of those, and the average of the two becomes the VcentDQ for the entire DRAM component and is used to center the eye mask against which you check. Walter agreed with Ken's description about how Vcent is calculated and the way the tool should optimize it. Ken noted that the question for an AMI model is whether the equalization functionality in the model, especially if it's adaptive, depends on the Vcent value. If it does, then the model has to know about Vcent. Fangyi noted that VrefDQ is used in the device itself, by the DFE, and is not necessarily equal to the VcentDQ used to check the mask. We generally expect them to be close, but they aren't necessarily the same thing. As Walter had previously noted, VrefDQ is optimized and set by the controller, while Vcent is a measurement result. Walter noted that Fangyi and Ken were "both right". VrefDQ in DDR5 is a register in the DRAM that the controller sets. The controller needs to go through some training methodology. It could be based on simulations and setup ahead of time, or it could be a training algorithm. Walter noted that Vref in legacy IBIS is something different and describes a voltage set at one end of the load under which timing measurements are done. Walter noted that VrefDQ implies a memory interface. He said that there may be other single-ended standards, but he preferred the name VrefDQ to avoid confusion. Arpad asked if we could use a name like VrefAMI in order to avoid being locked into something DRAM specific. Walter said he would be okay with that. He noted the VrefDQ is a register input in the DRAM set by the controller. In the future, it's conceivable the DRAM might determine VrefDQ itself, but that hasn't been the case for DDR4/5. Fangyi noted that this raised the question of how the AMI flow would work and how the VrefDQ (VrefAMI) would be set. Arpad said it sounded like a back- channel scenario. Walter noted that the memory Tx model has no equalization at all. The memory Rx model has DFE taps that need to be determined, and the controller needs to set the VrefDQ and adjust the skew between the controller DQS and DQs during writes. The controller may have these preset ahead of time and may set the registers in the DRAM as part of the bios, or the controller may figure it out with a training process. If it's a training process, then we can think about how we would use a BIRD147 type flow for training. Ambrish asked if, for a first pass at an AMI flow, the user could enter VrefDQ. Walter said yes. Fangyi noted that VrefDQ depends on the voltage supply in channel, and asked if Ambrish wanted the user to do some manual simulations to figure it out the value to set for VrefDQ. Ambrish said the tool could figure it out. Ambrish noted that memory experts he had consulted with said the DFE in their hardware is actually differential, so they would prefer that differential waveforms be sent into the model. The simulator could take care of the DC common mode (VrefDQ) issue. Walter noted that in the picture he had sent out in response to Arpad's Vref email, VrefDQ essentially makes the waveform differential. He noted that he and Ambrish agreed that the common mode info could be pulled into VrefDQ. He noted that if we decided we wanted to do other things like pass in a full single-ended waveform, for example to model certain saturation effects, then we would need to modify the standard. Arpad asked if we might want a combination of a default mode in which the tool/user provides a value and a full training solution available if the Tx can train and determine the actual VrefDQ to set in the Rx. Ambrish said we could let the simulator handle all of this. It has the step response and the Vdd values, so it can figure it out. We ought to simply let the simulator handle the common mode shifting. Ken noted that the tool could figure it out from the step response, or optionally let the user override it. Arpad noted the either way we would need a reserved parameter for the Rx to take in the value. Ambrish said that to keep it simple we should simply document things and let the simulator keep track of the common mode shifting. Arpad asked if we would want a reserved parameter for the Tx to pass the value out and the Rx to take it in. Walter said that was more complicated than necessary. If the Tx wanted to train then it could use back-channel to set the Rx. Ambrish said we should go with the simplifying assumption that the differential waveform will suffice and the tool can handle the common mode shifting. Ken noted that we could have a reserved parameter that is optional, and if it's absent then the tool just handles it. Fangyi disagreed. He said that if we say the input to the model is a differential signal, then the model doesn't need Vref because the DFE operates on a differential signal and the slicer compares to 0V. If we go that way, then we are saying we don't need this parameter at all. Even if we did introduce the parameter, we can't allow the user to arbitrarily set a value to it. They might set something that violates the physical electrical conditions of the circuit. The user can't be allowed to enter some arbitrary value that might be nonsense. Fangyi then noted that he wasn't sure it was a good idea to follow this path and keep the AMI waveform as differential even for a single-ended device. He noted that if we instead pass in the full single-ended waveform the VrefDQ would have a totally different meaning. Ambrish suggested that it was not necessary to move away from the differential waveform. Doing so would make the models more complicated and the tools dumber. Fangyi noted that if at some future time we wanted to include a training method for VrefDQ, then keeping the waveform differential might preclude that. Ambrish said nothing prevented us from adding it in the future if necessary. Fangyi said this was a chance to make the AMI interface more extensible and more physical and allow us to move beyond SERDES. Ambrish said that speeds are only going to go up from here, and we may even find a CDR in future DDR standards. Therefore, he suggested it was not worth spending time on adapting AMI to single-ended applications if the existing differential solution could be made to work. He thought everything would be trending toward differential anyway. Fangyi noted that DDR5 has a mix of single-ended and differential signals, and if we take care of them now we are more future proof. Fangyi also noted that as it currently stands VrefDQ is shared amongst all the DQs in a byte lane. But it's not physically the same for each DQ, and the JEDEC spec actually captures that variance of Vcent within the byte lane. Fangyi said this was the opportunity to address a lot of issues and make this sustainable for future DDR development. Arpad asked how many more single-ended signaling interfaces we expected to see in the future. Is it worth the time to try to extend to single-ended, or will it fade out soon anyway? What's beyond DDR5? Randy said DDR5, LPDDR5, and DDR6 will retain single-ended equalization, and suggested that's probably at least five years. Walter noted that he had also spoken Steve Parker about non-DDR single-ended interfaces. Fangyi noted he had heard from other vendors interested in single-ended too. Ambrish said the question wasn't single-ended vs. differential interfaces. The question should be: How much are we losing by keeping things simple and using a differential waveform, and what would we gain by going to single-ended? Walter noted that even if your model treats the signal as differential, you still need VrefDQ to figure out saturation curves. Fangyi said that if your model needs a differential signal and a VrefDQ, then it really needs a single- ended signal. So why bend over backwards to force it into the current form and send in a differential signal and a VrefDQ? Why not pass in the full single- ended signal and take advantage of it? Ambrish countered by asking why we should complicate things and modify the existing spec. if we could get good results staying with differential and possibly an extra offset parameter. Arpad asked if we had enough to begin working on a BIRD. Fangyi said he felt the single-ended vs. differential waveform was the fundamental question to answer, and it is still open. Answers to other questions, like step response vs. IR, would follow from this decision. He noted another issue was whether we wanted to consider a component-based model. Ambrish noted that they were planning on writing a BIRD on a common clock reference, which they considered the most important topic (assuming we decide we don't need to change to single-ended waveforms). Walter noted 3 issues: 1. Who is going to generate that DQS signal? 2. Do the IC vendors think there is a need for that clock? There is no CDR in DDR5, but what you need in modeling is a clock with a phase. So, the Rx model could have a CDR in it. In reality the hardware on the controller figures it out. But since you're asking the Rx what the best phase is, according to bit-error-rate, the Rx model can determine the best phase. 3. Or, do the IC controller vendors want to be able to develop and model their own training methods? In that case, having a CDR on the Rx side might not be good enough. - Michael M.: Motion to adjourn. - Ken: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 11 September 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives